제한된 시스템은 다음과 같다.
BMP가 문제다.
RAM : 수십키로. 현재 20KB
ROM : 시리얼 플래시로서 1Mbit 정도.
클럭 : 50Mhz - 60Mhz
컬러타겟 : RGB - 5-6-5 / 16bit
동적 메모리 할당은 곤란한 상황. 가비지 컬렉션 따위도 있을리가 없..
사실 이보다 커질수도 있고 작을 수도 있다.
SDRAM을 달거나 NAND를 달면 널널해지지만 시스템은 방만해지고 가격 상승.
RTOS가 들어가거나 MMU가 달렸다면 몇가지 유리한 점이 있지만. 일단 여기서는 제외.
그래서 몇 가지 검토 결과는 이러하다.
GIF : 저작권 문제 드롭
JPG
문자등을 처리할 때 양자화 문제로 열화가 두드러진다.
사진이 아닌 UI 타겟으로는 어려움이다.
비교적 대용량의 테이블 용량이나 코드 사이즈를 가진다.
허프만 코딩만 따로 써볼까? 트리 구성의 압박이 느껴진다. 일단 제외하자. 어렵다.
PNG
공개, 화질 열화 없음.
오픈소스를 몇몇 디벼본결과 libpng, libz 와 같은 범용 라이브러리로부터 시작되며.
그런 범용라이브러리를 잘라내서 쓰거나 모두 담을 그릇이 없다 -_-;
알고리즘만 보고 새로 짜기는 능력없다.
RLE --> PCX 기본 알고리즘
PCX를 뜯어고치거나 그레이 BMP에서 사용되는 RLE를 고쳐서 사용해보고자 함.
구조는 닥터할로 시절에도 그러했듯이 다음과 같다. AAAAAA -> A6 로 압축.
이 기법을 응용해보니 상당히 훌륭했다. 허나 실사용 파일을 적용해보니 좌절. 용량이 더 커진다.
결론 : 디더링의 문제 / UI등에서 사용되는 그라데이션들은 디자이너가 24비트로 작업후 16비트 다운시에 디더링이 먹는다.
디더링 먹은 컬러는 연속된 점도 존재하지 않고 패턴자체도 미묘하다. 밝은파랑-물빠진파랑-어둔파랑-밝은파랑-물먹은파랑-칙칙한파랑...
선택한 알고리즘
Lempel-Ziv : 일명 LZ 알고리즘이다. 허프만 바로 전 단계의 압축기법이라 할 수 있다.
소스 조금 고치면 배열을 1-2키로만 쓰고도 디코딩이 가능하다. 어차피 타겟 머신에서 인코딩은 필요없다.
알고리즘이나 소스는 인터넷에 많다.
http://search.naver.com/search.naver?where=post&sm=tab_nmr&query=Lempel-Ziv
뚝딱뚝딱 순식간에 참고한 곳은.
http://joyholic.kr/41
압축효율
그라데이션 배경의 평범한 UI -> 기존 파일 대비 20% 사이즈로 압축 (최대)
색상이 화려하지 않은 사진 -> 기존 파일 대비 70% 사이즈로 압축
속도는 소요 틱 체크 타이머 계산이 귀찮아서 안 해봤는데..
체감상 10% 정도 느려지는 듯. 이 정도면 상당히 훌륭하다. 디코딩 자체는 매우 단순하기에.
이로서 초경량 시스템에서 수월하게 그림 처리를 할 수 있게 되었다.
뭐. 이상...